1. Field of the Invention
A system and method for management and notification of changes in condition of electronic certificates is disclosed. Specifically, a system and method for allowing electronic certificate users to contract with a server for receiving notifications of changes in conditions of electronic is disclosed.
2. Description of the Prior Art and Related Information
A public key infrastructure (PKI) enables users of a public network, such as the Internet, to securely and privately exchange data and money through the use of public and private cryptographic key pairs. The public key of the key pair may comprise all or part of a digital, or electronic, certificate. The public key infrastructure provides for electronic certificates that can identify individuals or organizations and directory services that can store and, when necessary, revoke them. Although the components of a PKI are generally understood, a number of different vendor approaches and services are emerging. Meanwhile, Internet standards for PKIs are currently being developed.
The public key infrastructure assumes the use of public key cryptography, which is the most common method on the Internet for authenticating a message sender or encrypting or decrypting a message. Traditional cryptography has usually involved the creation and sharing of a private key for the encryption and decryption of messages: This secret key system has the significant flaw that if the key is discovered or intercepted by someone else, messages can easily be decrypted. For this reason, public key cryptography and the public key infrastructure is the preferred approach on the Internet. The secret key system is sometimes known as symmetric cryptography and the public key system as asymmetric cryptography.
A public key infrastructure (PKI) may comprise a certificate server that may comprise a certificate authority (CA) that issues, verifies, signs, and/or stores electronic certificates. The certificate server may further comprise a server having an X.509 directory or a PGP key server. An electronic certificate may include the public key or information about the public key. The infrastructure may further include registration authorities (RAs) which act as verifiers for the certificate server before an electronic certificate is issued to a requester. The infrastructure may further include one or more directories where the electronic certificates, with their public keys, are stored, usually in an ITU X.500 standard directory. The electronic certificates are managed by a certificate management system.
In public key cryptography, the public key and corresponding private key are created using a cryptographic algorithm, such as the popular algorithm known as RSA, typically by the owner of the private key. The public key is then embodied in an electronic certificate that may be issued by a certificate authority, or perhaps self-issued by the owner of the private key, and then the certificate is made publicly available in a directory that all parties can access. The private key is not disclosed to outside parties. Thus, if a user of the electronic certificate wants to send a message to the holder of the private key, who is the owner of the electronic certificate, the user may find the owner's electronic certificate, but not the owner's private key, on the certificate server's directory and encrypt a message to the owner using the public key. When the owner of the electronic certificate receives the message, the owner may decrypt it with the owner's private key. In addition to encrypting messages (which ensures privacy), the user can authenticate itself to the owner by using the user's private key to sign an electronic digest. When the owner receives the message, the owner can use the user's public key to verify the message.
A number of current products enable a company or group of companies to implement a PKI. The acceleration of e-commerce and business-to-business commerce over the Internet has increased the demand for PKI solutions. Related ideas are virtual private networks (VPNs) and the IP Security (IPSec) standard. Some PKI system vendors include:                RSA Security, Inc., which has developed the main algorithms used by PKI vendors;        Verisign, which acts as a certificate authority and sells software that allows a company to create its own certificate authorities;        GTE, which provides a system called CYBERTRUST, which provides a PKI implementation methodology and consultation service;        Check Point, which offers a product, VPN-1 CERTIFICATE MANAGER, that is based on the NETSCAPE DIRECTORY SERVER;        Xcert, whose WEB SENTRY product checks the revocation status of certificates on a server, using the online certificate status protocol (OCSP);        Netscape, whose DIRECTORY SERVER product is said to support 50 million objects and process 5,000 queries a second; and whose SECURE E-COMMERCE product allows a company or extranet manager to manage electronic certificates; and whose META-DIRECTORY product can connect all corporate directories into a single directory for security management; and        Entrust Technologies of Plano, Tex., which is another prominent PKI vendor.        
For e-mail, the PRETTY GOOD PRIVACY (PGP) product by Network Associates, Inc. of San Jose, Calif., lets users encrypt a message to anyone who has a PGP public key. A user encrypts a message with recipient's public key and the certificate owner decrypts the message with their private key. PGP users share directories of public keys stored on PGP key servers. As another option, PGP lets the user digitally sign the message with a digital signature using the user's private key. The recipient who is the certificate's owner can then get the user's public key and verify the user's signature to see whether it was really the user who sent the message.
An electronic certificate can also be used as an electronic credit card that establishes the owner's credentials when doing business or other transactions on the Internet or other networks. It is typically issued by a certificate authority, and contains the owner's name, a serial number, expiration dates, a copy of the certificate holder's public key, and the digital signature of the certificate authority so that a recipient can verify that the certificate is real. Some electronic certificates conform to a standard known as X.509.
One of the most common problems with PKIs, and the like, is that when certificates change, it is generally up to all the users of the electronic certificate to find out that such a change occurred. Often, users are too busy to check all of the electronic certificates that they use, or do not have the resources to constantly do so. Further, if a user does decide to check if a particular electronic certificate has changed, they must search through large databases on the certificate server. An example of a change in condition of an electronic certificate is revocation of the electronic certificate, that is declaring the electronic certificate to be invalid.
Attempts have been made to solve the shortcomings of the prior art, at least with respect to revocation. For example, U.S. Pat. No. 5,687,235 discloses an electronic certificate revocation process that improves the efficiency of an authentication exchange in a public key distributed network system. Specifically, the revocation service (RS) that, in response to a unique request from a server node, selects certain revoked electronic certificates from a current certificate revocation list (CRL) to include in its reply so as to consume minimal system bandwidth is described. The unique request includes a number of parameters for consideration by the RS in generating its reply, including a maximum CRL size and/or a timestamp. The maximum CRL size indicates the largest number of revoked certificate serial numbers that the server node can process and thus receive in the revocation service reply, whereas the timestamp indicates the latest electronic certificate revocation date of the certificates included in the CRL presently retained by the server node. The RS generates an optimal CRL for its reply that contains all, part, or none of the current CRL revoked certificate serial numbers. Determination of the optimal CRL entails consideration of any number and combination of optimization factors, including the number of revoked certificates stored in the CRL storage facility and the time remaining before the current CRL is to be updated by a certificate authority (CA), the expiration date of the certificates, as well as the maximum CRL size and/or timestamp parameters provided to the RS in the server node request. The server node may control whether it will receive an optimal CRL and if so, what portion of the current CRL it will include by manipulating the parameters it provides to the RS. This enables each server node to request the CRL based upon its own specific security needs while optimizing the certificate revocation process. Further, the RS and/or server node may discard certificate serial numbers as their expiration dates come to pass.
U.S. Pat. No. 5,666,416 discloses a method of managing electronic certificates in a communication system having a certifying authority and a directory. The method begins by having the certifying authority generate electronic certificates by digitally signing a given piece of data. At a later point time, the certifying authority may produce a string that proves whether a particular electronic certificate is currently valid without also proving the validity of at least some other certificates. The technique obviates use of certification revocation lists communicated between the certifying authority and the directory.
U.S. Pat. No. 5,793,868 discloses a method for authenticating information about revoked electronic certificates that includes generating data identifying the revoked electronic certificates, generating information about the revoked electronic certificates including the data without including the revocation date of every one of the revoked electronic certificates, and having the certificate authority authenticate the information. The data may be generated by performing a hash of at least a portion of each of the electronic certificates. Generating information about the revoked electronic certificates may include adding a date indicating when the information was authenticated and may exclude the revocation date of any one of the revoked electronic certificates in the list.
None of the above mentioned systems solve the problems associated with the user of an electronic certificate having to take a proactive role in tracking and dealing with changes in conditions of electronic certificates. Further, none of the above systems provide for a notification service for changes in conditions of electronic certificates. Further, none of the above systems provide a system for collecting revenues for such a notification system.